Live MQTT-Steuerung

tipp

Die Live-MQTT-Steuerung ist für die Live-Steuerung gedacht. Für das Senden von Zeitplänen im Voraus siehe stattdessen Geplante MQTT-Steuerung.

Dieser Leitfaden hilft Ihnen, MQTT auf Ihrem SmartgridOne Controller zu konfigurieren, um Batterie- und Solaranlagen aus der Ferne zu steuern und zu überwachen.

Was Sie benötigen

1. SmartgridOne Controller mit Internetverbindung.
2. MQTT-Anmeldeinformationen: Diese können angefordert werden, indem Sie eine E-Mail an support@eniris.be senden.
3. Python-Entwicklungsumgebung (oder jeden anderen MQTT-Client). Dieser Leitfaden verwendet ein einfaches Beispiel, das in Python geschrieben ist, um Ihnen den Einstieg in MQTT und das Senden von Befehlen zu erleichtern. Wir empfehlen, Python wegen der Benutzerfreundlichkeit zu verwenden, aber jeder andere MQTT-Client wird unterstützt.

Zusätzliche Informationen

MQTT ist ein schnelles Kommunikationsprotokoll über das Internet. Es handelt sich um ein Publish/Subscribe-Nachrichtensystem, das eine direkte Verbindung zwischen Ihrem Gerät und dem SmartgridOne Controller ermöglicht. Ihre Anlagen sind in Gruppen wie Solar, Batterie, EV und HVAC eingeteilt.

Erstkonfiguration (Ausgangspunkt für neue Benutzer)

Ich habe einen SmartgridOne Controller, den ich für die MQTT-Fernsteuerung einrichten möchte.

1. Überprüfen Sie Ihr Netzwerk

Stellen Sie sicher, dass Ihr Netzwerk den MQTT-Datenverkehr über Port 1883 zulässt. Sie können dies mit dem Befehl tun:

nc -zv mqtt.eniris.be 1883

Wenn dieser Befehl nicht verfügbar ist, können Sie alternativ diesen Python-Code herunterladen und ausführen.

Wenn Sie unsicher sind, konsultieren Sie Ihren Netzwerkingenieur oder verwenden Sie vorübergehend den 4G/5G-Hotspot Ihres Telefons, wenn Verbindungsfehler auftreten.

hinweis

Wenn Port 1883 aus Ihrem Netzwerk nicht zugänglich ist, bieten wir einen Backup-Port 80 an. Dies kann in einem späteren Schritt in Ihrem MQTT-Client konfiguriert werden.

2. Fügen Sie Ihre Geräte hinzu

Loggen Sie sich in die Inbetriebnahmeoberfläche ein und stellen Sie sicher, dass die Geräte hinzugefügt werden zum SmartgridOne Controller.

3. Fügen Sie das MQTT-Ext-Signal hinzu

4. Aktivieren Sie das MQTT-Fernsignal

Das Feld 'VPP ID' muss leer gelassen werden.

Der Timeout des Fallback-Mechanismus informiert dem SmartgridOne Controller, wie lange es auf neue Befehle warten soll. Wenn der SmartgridOne Controller keine Befehle mehr empfängt, übernimmt er nach diesem Timeout automatisch die Standardstrategie.

Wählen Sie anschließend alle Geräte aus, die Sie in die MQTT-Fernsteuerung einbeziehen möchten.

5. Fernsignal wurde hinzugefügt

Die MQTT-Fernsteuerungsoberfläche wurde jetzt auf dem SmartgridOne Controller aktiviert.

Wir sind jetzt bereit, einige grundlegende Befehle mit einem einfachen Beispiel zu senden. Die Statusspalte zeigt Ihnen an, ob ein Befehl aktiv ist.

Python-Demoskript

Ein guter erster Ausgangspunkt wäre, Ihre neu eingerichtete Integration mit einem einfachen Beispiel zu testen.

Dieser Testcode führt die einfache Aufgabe aus, kontinuierlich die folgenden Befehle zu senden:

• Batterie: Laden mit 5 kW
• Solar: Leistung auf 0 kW einstellen

Der SmartgridOne Controller antwortet kontinuierlich mit einer 'Feedback'-Nachricht, die die beobachteten Werte der Netz- und Anlagenleistung enthält. Diese Funktion ist auch in diesem Beispiel enthalten.

Bitte laden Sie die Datei unten in Ihrer bevorzugten Python-IDE herunter. Füllen Sie Ihre Seriennummer und MQTT-Anmeldeinformationen aus und führen Sie das Skript aus:

Wenn das oben Genannte erfolgreich ist, können Sie mit dem Senden anderer Arten von Befehlen fortfahren. Alle Befehle sind in unserer MQTT-Fernsteuerungsdokumentation beschrieben.

MQTT-Dokumentation zum Senden von Befehlen

Dieser Abschnitt beschreibt das MQTT-Nachrichtenformat und die Payload-Anforderungen für die Fernsteuerung von Energiepolitiken auf Geräten im Netzwerk des SmartgridOne Controller.

MQTT-Thema

Das MQTT-Thema, das zum Senden von Befehlen verwendet wird, ist wie folgt strukturiert:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Dabei sollte 'controller SN' mit der tatsächlichen Seriennummer des SmartgridOne Controller ersetzt werden, den Sie steuern möchten.

MQTT-Payload-Struktur

Befehle werden als JSON-Payloads gesendet. Die Payload-Struktur ist so konzipiert, dass sie verschiedene Energieverwaltungsrichtlinien und Vorgabewerte für verschiedene Komponenten des Smart-Grid-Systems angibt. Hier ist die Gliederung der Payload mit detaillierten Feldbeschreibungen:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>
    }
}

Feldbeschreibungen

tipp

Mehrere Gerätetypen (z. B. Batterien + Solar) können gleichzeitig gesteuert werden.

• extraTags (Objekt):
  • nodeId (String): Ein eindeutiger Identifikator für den Knoten im Netzwerk des SmartgridOne Controller. Dies entspricht Ihrer Seriennummer, gefolgt von '_site_0' für die meisten SmartgridOne Controller-Geräte.
• time (Integer): Unix-Zeitstempel in Sekunden, der die Zeit angibt, zu der die Nachricht gesendet wird.
• fields (Objekt):
  • <Component>_policy (String): Richtlinientyp für die Komponente. Es ist optional, und wenn es nicht angegeben wird, fällt das System auf die Standardeinstellung des SmartgridOne Controller zurück.
  • <Component>_power_setpoint_w (Float): Gewünschter Leistungsvorgabewert in Watt für die Komponente. Dies ist optional und nur relevant, wenn eine entsprechende Richtlinie festgelegt ist.

Komponenten und Richtlinien

info

Anlagen desselben Typs (z. B. zwei Batterien) werden als eine Komponente zusammengefasst. Wenn beispielsweise zwei 5 kWh-Batterien installiert sind, wird dies als eine 10 kWh-Batterie behandelt.

Jede Komponente im fields-Objekt kann eine Richtlinie und einen Leistungsvorgabewert enthalten. Die folgenden Komponenten können gesteuert werden:

• solar_policy und solar_power_setpoint_w:

  • Steuerung der Richtlinie und des Vorgabewerts für die Solarstromerzeugung. Unterstützte Richtlinien:
    • Richtlinie Vorgabewert: Legt die maximale Leistung fest, die von allen angeschlossenen Solaranlagen erzeugt wird. Das Feld solar_power_setpoint_w sollte auf das Produktionsleistungsgrenze in Watt gesetzt werden.
    • Richtlinie Einspeisebeschränkung: Produzieren Sie mit voller Leistung, unter Berücksichtigung der aktuellen Netzgrenzen.
    • Richtlinie Kosten: Ermöglicht die Minimierung der Kosten für die Solarproduktion auf Basis der Tagespreise (EPEX Spotmarkt). Bei negativen Einspeisepreisen reduzieren wir die Produktion auf unseren Verbrauch. Wenn sowohl der Abnahme- als auch der Einspeisepreis negativ sind, schalten wir alle Solaranlagen ab. Das Feld solar_power_setpoint_w wird ignoriert.
    • Richtlinie Aus: Deaktiviert alle Interaktionen für alle Solaranlagen. Achtung: In diesem Modus werden keine Grenzen gewahrt. Das Feld solar_power_setpoint_w wird ignoriert.

• storage_policy und storage_power_setpoint_w:

• Steuert die Richtlinie des Energiespeichersystems sowie die Lade- oder Entladeleistung.

  • Richtlinie Sollwert: Setzen Sie die gesamte Ladeleistung (positiver Sollwert) oder Entladeleistung (negativer Sollwert) für die Gruppe von Batterien. Wenn mehrere Batterien angeschlossen sind, wird der Sollwert entsprechend der verfügbaren Lade-/Entladeleistung aufgeteilt, um die Batterien gleichmäßig zu belasten. Das Feld storage_power_setpoint_w wird auf die gewünschte Batterieleistung gesetzt.
  • Richtlinie Kosten: Ermöglicht die Kostenoptimierung gemäß den Preisen einen Tag im Voraus (EPEX Spotmarkt) für die Batterien, indem sie in den günstigen Stunden aufgeladen und in den teuren Stunden verwendet werden. Das Feld storage_power_setpoint_w wird ignoriert.
  • Richtlinie Eigenverbrauch: Ermöglicht einen einfachen Eigenverbrauchsalgorithmus für die Batterien. Überschüssige Solarproduktion wird in die Batterie gespeichert, und wenn die Sonne nicht mehr scheint, wird Energie aus der Batterie entnommen. Das Feld storage_power_setpoint_w wird ignoriert.
  • Richtlinie aus: Deaktiviert alle Interaktionen für alle Batterieanlagen. Warnung: Grenzen werden in diesem Modus nicht überwacht. Das Feld storage_power_setpoint_w wird ignoriert.

• heat_pump_policy:

  • Schaltet die Wärmepumpensysteme ein/aus. Die Mindest- und Höchstlaufzeiten werden immer eingehalten.
    • Richtlinie Kosten: Ermöglicht die Kostenoptimierung gemäß den Preisen einen Tag im Voraus (EPEX Spotmarkt) für die Wärmepumpen. Der lokale dynamische Preisalgorithmus entscheidet über die besten Betriebszeiten.
    • Richtlinie Eigenverbrauch: Schaltet die Wärmepumpen ein, wenn ein Überschuss an Solarenergie produziert wird.
    • Richtlinie abschalten: Schaltet die Wärmepumpen aus.
    • Richtlinie einschalten: Schaltet die Wärmepumpen ein.

• switched_load_policy:

  • Schaltet relaisgesteuerte Systeme ein/aus. Das könnte das integrierte Relais oder netzverbundene Relais sein.
    • Richtlinie Kosten: Ermöglicht die Kostenoptimierung gemäß den Preisen einen Tag im Voraus (EPEX Spotmarkt) für das Relais.
    • Richtlinie Eigenverbrauch: Schaltet das Relais ein, wenn ein Überschuss an Solarenergie produziert wird.
    • Richtlinie abschalten
    • Richtlinie einschalten

• variable_power_load_policy und variable_power_load_power_setpoint_w:

  • Verwalten die Richtlinie und den Sollwert des Stromverbrauchs von Elektrofahrzeugen.
    • Richtlinie Sollwert: Setzen Sie die gesamte Ladeleistung für die Gruppe von Elektrofahrzeugen. Das Feld variable_power_load_power_setpoint_w wird auf die gewünschte Ladeleistung gesetzt.
    • Richtlinie Kosten: Ermöglicht die Kostenoptimierung gemäß den Preisen einen Tag im Voraus (EPEX Spotmarkt) für die Batterien, indem sie in den günstigen Stunden aufgeladen werden. Das Feld variable_power_load_power_setpoint_w wird ignoriert.
    • Richtlinie Eigenverbrauch: Ermöglicht das Laden, wenn ein Überschuss an Solarenergie produziert wird. Das Feld variable_power_load_power_setpoint_w wird ignoriert.
    • Richtlinie aus: Deaktiviert alle Interaktionen für alle Elektrofahrzeuge. Das Feld variable_power_load_power_setpoint_w wird ignoriert.

• site_policy und site_power_setpoint_w:

  • Verwalten die Exporteinschränkungen für den Standort.
    • Richtlinie Export: Setzen Sie die Exporteinschränkung für den Standort. Das Feld site_power_setpoint_w wird auf die Exporteinschränkung gesetzt.
    • Richtlinie Standard: Setzt die Standorteinschränkung auf die Standardexportleistung zurück, die in der Steuerungskonfiguration festgelegt ist.

Gerätesteuerung

Bestimmte Geräte können auch gesteuert werden, anstatt Gruppen von Geräten nach ihren Typen. Die Nachricht ist identisch strukturiert:

• nodeId_policy und nodeId_power_setpoint_w

When two commands are sent to the same asset (e.g. one device-specific command to a solar inverter, and a command to all solar devices), the device-specific control method will take preference over the device type control.

Fallback-Verhalten

Für jede Komponente, falls die _policy und _power_setpoint_w nicht angegeben sind, verwendet das System automatisch die konfigurierte Fallback-Richtlinie im SmartgridOne Controller. Dies stellt sicher, dass jedes Gerät oder jede Gerätegruppe sicher betrieben wird und weiterhin funktioniert, auch wenn keine spezifischen Anweisungen vorliegen.

Wenn überhaupt kein Befehl gesendet wird, werden nach 60 Sekunden (oder der konfigurierten Timeout-Periode) die Standardrichtlinien für die Anlagen reaktiviert.

Vorhandene Befehle abbrechen und Rückfall auf lokale Steuerungsmodi

Ein aktiver Befehl kann durch das Senden einer Fallback-Befehls-Nachricht abgebrochen werden.

Fallback-Befehl

Ein Fallback-Befehl wird den vorhandenen Befehl sofort abbrechen und die SmartgridOne Controller wird die Kontrolle über die Installation übernehmen. Die ausgeführte Richtlinie hängt von dem ab, was in den Einstellungen der SmartgridOne Controller festgelegt ist.

Dies kann auch in Fällen verwendet werden, in denen ein sekundäres Steuersignal, wie ein Zeitplan, als Rückfall verwendet wird.

Nachricht Beispiele:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "fallback",
    }
}

Leerer Befehl

Ein leerer Befehl kann jederzeit gesendet werden, um Standortinformationen zu sammeln. Dies wird den aktuellen Befehl nicht abbrechen und keine Befehle von sekundären Steuersignalen mit niedrigerer Priorität überschreiben.

Der leere Befehl ist wie folgt strukturiert:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {}
}

Beispielpayload

Unten ist ein Beispiel für eine Payload, um verschiedene Richtlinien und Sollwerte festzulegen:

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

In diesem Beispiel wird die Solarleistung auf bis zu 5000 Watt eingestellt, und das Energiespeichersystem wird entweder mit einer Rate von 5000 Watt aufgeladen oder entladen, abhängig vom Vorzeichen des Sollwerts. Wenn entweder die solar_policy oder die storage_policy weggelassen würde, würde das jeweilige Gerät auf die Standardwerte zurückfallen, die von der SmartgridOne Controller festgelegt wurden.

MQTT-Dokumentation zum Empfang von Feedback

Dieser Abschnitt beschreibt die Struktur und den Inhalt der Feedbacknachrichten, die von der SmartgridOne Controller über MQTT gesendet werden. Diese Nachrichten werden an das Thema standard1/outbound/remoteControlMetrics/feedback/<Controller SN> veröffentlicht, nachdem ein Befehl verarbeitet wurde.

MQTT-Feedback-Thema

Das Feedback-MQTT-Thema ist wie folgt strukturiert:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Dabei sollte <Controller SN> mit der Seriennummer der SmartgridOne Controller ersetzt werden, die das Feedback sendet.

Struktur des MQTT-Feedback-Payloads

All assets are grouped by their type. This means that two individual solar installations of 3 kW will be treated as one 6 kW asset.

Feedback-Nachrichten sind im JSON-Format strukturiert. Diese Payloads bieten detailliertes Feedback über den Status des Systems nach der Anwendung der Sollwertbefehle unter Berücksichtigung der Netz-/Gerätelimits. Unten steht die Struktur des Feedback-Payloads mit Beschreibungen seiner Felder:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Grid Active Power in Watts>,
                "today_imported_energy_Wh": <Grid Imported Energy in Watt-hours>,
                "today_exported_energy_Wh": <Grid Exported Energy in Watt-hours>,
                "import_limit_W": <Grid Import Limit in Watts>,
                "export_limit_W": <Grid Export Limit in Watts>,
            },
            "vpp_id": "<Virtual Power Plant Identifier>",
            "storage": {
                "energy_stored_Wh": <Energie gespeichert in Wattstunden>,
                "energy_capacity_Wh": <Gesamte Energiespeicherkapazität in Wattstunden>,
                "mean_soc_perc": <Durchschnittlicher Ladezustandsprozentsatz>,
                "active_power_W": <Aktive Leistung in Watt>,
                "executed_power_W": <Leistungs-Setpoint an Geräte gesendet in Watt>,
                "executed_policy": <Politik, die vom Controller ausgeführt wurde>,
                "max_charge_power_W": <Maximale Ladeleistung in Watt>,
                "max_discharge_power_W": <Maximale Entladeleistung in Watt>,
                "today_charged_Wh": <Energie, die heute in Wattstunden geladen wurde>,
                "today_discharged_Wh": <Energie, die heute in Wattstunden entladen wurde>,
                "nr_devices": <Anzahl der installierten gesteuerten Speichereinheiten>
            },
            "solar": {
                "active_power_W": <Aktive Solarleistung in Watt>,
                "executed_power_W": <Leistungs-Setpoint an Geräte gesendet in Watt>,
                "executed_policy": <Politik, die vom Controller ausgeführt wurde>,
                "capacity_W": <Solarleistung in Watt>,
                "today_energy_Wh": <Heute produzierte Energie in Wattstunden>,
                "nr_devices": <Anzahl der installierten gesteuerten Solargeräte>
            },
            "heat_pump": {
                "executed_policy": <Politik, die vom Controller ausgeführt wurde>,
                "operation_modes": <Betriebsarten der Wärmepumpe>,
                "executed_power_W": <Leistungs-Setpoint an Geräte gesendet in Watt>,
                "nr_devices": <Anzahl der installierten gesteuerten Wärmepumpen>
            },
            "switched_load": {
                "executed_policy": <Politik, die vom Controller ausgeführt wurde>,
                "devices_on": <Anzahl der eingeschalteten Geräte>,
                "devices_off": <Anzahl der ausgeschalteten Geräte>,
                "executed_power_W": <Leistungs-Setpoint an Geräte gesendet in Watt>,
                "nr_devices": <Anzahl der installierten gesteuerten geschalteten Lasten>  
            },
            "variable_load": {
                "executed_policy": <Politik, die vom Controller ausgeführt wurde>,
                "executed_power_W": <Leistungs-Setpoint an Geräte gesendet in Watt>,
                "active_power_W": <Leistung des Geräts in Watt>,
                "ev_requiring_charge": <Benötigt das Elektrofahrzeug eine Aufladung>,
                "currentL1_A": <Strom des Geräts in Phase 1 in Ampere>,
                "currentL2_A": <Strom des Geräts in Phase 2 in Ampere>,
                "currentL3_A": <Strom des Geräts in Phase 3 in Ampere>,
                "executed_current_A": <Strom-Setpoint an Geräte gesendet in Ampere>,
                "today_charged_Wh": <Energie heute in Wattstunden geladen>,
                "today_discharged_Wh": <Energie heute in Wattstunden entladen>,
                "total_charged_Wh": <Gesamte Energie in Wattstunden geladen>,
                "total_discharged_Wh": <Gesamte Energie in Wattstunden entladen>,
                "min_charge_current_A": <Minimale Ladung in Ampere>,
                "max_charge_current_A": <Maximale Ladung in Ampere>,
                "allow_zero_current": <Unterstützt das Ladegerät das Pausieren>,
            }
        },
        "response_code": <Antwortcode>
    },
    "fields": {},
    "requestTime": "<Unix-Zeitstempel>",
    "time": "<Unix-Zeitstempel>",
    "siteNodeId": "<Controller SN>_site_0"
}

            - executed_policy (Str): Die Richtlinien, die auf die steuerbaren Elemente angewendet wurden,
            - executed_power_W (Float): Die Summe der insgesamt von den Anlagen angeforderten Leistung, die von unserem Kontrollalgorithmus ausgegeben wird.
            - active_power_W (Float): Repräsentiert die aktuelle aktive Leistung im Netz in Watt.
            - ev_requiring_charge (Bool): Benötigt das EV eine Ladung? (Ist ein Fahrzeug angeschlossen).
            - currentL1_A (Float): Strom des Geräts auf Phase 1 in Ampere.
            - currentL2_A (Float): Strom des Geräts auf Phase 2 in Ampere.
            - currentL3_A (Float): Strom des Geräts auf Phase 3 in Ampere.
            - executed_current_A (Float): Die Summe des insgesamt von den Anlagen angeforderten Stroms, die von unserem Kontrollalgorithmus ausgegeben wird.
            - today_charged_Wh (Float): Die heute in die EV-Ladeeinheit(en) geladene Energie. Hinweis: Heute wird in UTC-Zeit angegeben.
            - today_discharged_Wh (Float): Die heute aus der EV-Ladeeinheit(en) entnommene Energie. Hinweis: Heute wird in UTC-Zeit angegeben.
            - total_charged_Wh (Float): Die insgesamt in die EV-Ladeeinheit(en) geladene Energie.
            - total_discharged_Wh (Float): Die insgesamt aus der EV-Ladeeinheit(en) entnommene Energie.
            - min_charge_current_A (Float): Mindeststrom, bei dem das EV geladen werden kann.
            - max_charge_current_A (Float): Höchststrom, bei dem das EV geladen werden kann.
            - allow_zero_current (Bool): Erlaubt der EV-Ladegerät das Pausieren.
        - nodeId (Object):
            - Wenn eine nodeId im Befehl enthalten ist, enthält das Feedback den entsprechenden Status des Geräts.
    - response_code (Int):
        - Gibt den Status der Operation an. Ein response_code von 0 bedeutet normalerweise Erfolg, während andere Werte unterschiedliche Arten von Fehlern oder Statusinformationen anzeigen können (diese sollten in einem separaten Verweis detailliert beschrieben werden).

### Beispiel-Feedback Payload
Hier ist ein Beispiel für eine Feedback-Nachricht nach einem Befehl, um verschiedene Leistungsziele festzulegen:

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Image 1" maxWidth="450px" />

Dieses Feedback zeigt den aktuellen Betriebszustand des Systems nach der Ausführung der Leistungsziele und die Auswirkungen auf die Solarstromerzeugung, Speicherung und die gesamte Netzinteraktion an.

## Unterstützte MQTT-Versionen und Verhalten bei unautorisierten Themen
Bei der Verwendung von MQTT ist es wichtig, die Unterschiede in den Spezifikationen zwischen den Versionen 3.1, 3.1.1 und 5.0 zu berücksichtigen, insbesondere in Bezug auf das Verhalten des Brokers, wenn Clients auf unautorisierte Themen veröffentlichen.

Laut der MQTT 3.1.1-Spezifikation (siehe OASIS MQTT 3.1.1-Spezifikation, Abschnitt MQTT-3.3.5-2) muss ein Broker die Verbindung beenden, sobald ein Client ein PUBLISH an ein Thema sendet, für das er keine Berechtigung hat. Dieses Verhalten kann zu unerwarteten Trennungen für Clients führen, die versuchen, auf falsch konfigurierte oder nicht autorisierte Themen zu veröffentlichen.

In MQTT 3.1 ist dieses Erfordernis nicht vorhanden. Wenn ein Client unter dieser Version auf ein unautorisiertes Thema veröffentlicht, ignoriert der Broker typischerweise die Nachricht (stille Ablehnung), ohne die Verbindung zu beenden. Dadurch ist MQTT 3.1 in einigen Fällen besser geeignet, wenn Robustheit gegenüber Konfigurationsfehlern oder vorübergehend fehlenden Berechtigungen wichtiger ist als strenge Sicherheitsdurchsetzung.

Obwohl MQTT 5.0 die Möglichkeit einführt, mit Grundcodes (wie PUBACK mit einem Ablehnungsgrund) zu arbeiten, erfordert dies Unterstützung sowohl auf der Client- als auch auf der Serverseite. Der Umstieg auf MQTT 5.0 bedeutet daher zusätzlichen Implementierungsaufwand.

__Folgen der Ignorierung der Kompatibilität:__
Wenn ein Client sich mit MQTT 3.1.1 verbindet und versucht, Nachrichten an unautorisierte Themen zu veröffentlichen, wird die Sitzung vom Broker abrupt beendet. Dies kann zu Instabilität, Verlust der Konnektivität oder erhöhter Belastung aufgrund wiederholter Wiederverbindungsversuche führen.

__Empfohlener Ansatz:__
Für Systeme, in denen Clients möglicherweise (vorübergehend) versuchen, auf unautorisierte Themen zu veröffentlichen, oder in denen die Fehlerbehandlung nicht strikt implementiert ist, empfehlen wir die Verwendung von MQTT 3.1. Dies sorgt für stabilere Verbindungen und vermeidet unbeabsichtigte Trennungen während der Laufzeit.